Description

This PR implements responsive design improvements for SwaggerUI operations on screens below 360px width. The changes ensure that API operation summaries remain readable and usable on narrow mobile devices by implementing progressive font size reductions and optimized spacing.

Key improvements:

• Added @media (max-width: 360px) and @media (max-width: 320px) breakpoints
• Progressive font size scaling: normal → small (360px) → extra small (320px)
• Optimized padding and spacing for narrow screens
• Enhanced wrapper padding for better mobile experience

Motivation and Context

Fixes #8940 - Compensate Operation content in lower resolution sizes

Problem: SwaggerUI operation blocks become unreadable on devices with screen widths below 360px. Text becomes too cramped and operation information is difficult to read on narrow mobile screens.

Solution: Implement progressive responsive scaling that maintains readability while optimizing space utilization on very narrow screens.

How Has This Been Tested?

Manual Testing:

1. Created test-responsive.html with simulated operation blocks to validate responsive behavior

2. Tested breakpoints at 360px, 320px, and below using browser developer tools

3. Verified font size scaling works correctly:

   • Normal screens (>360px): Standard sizes (14px methods, 16px paths, 13px descriptions)
   • Small screens (≤360px): Reduced sizes (10px methods, 10px paths, 11px descriptions)
   • Very small screens (≤320px): Minimal sizes (9px methods, 9px paths, 10px descriptions)

4. Confirmed padding and spacing optimizations improve space utilization

5. Validated that all changes maintain visual hierarchy and readability

Testing Environment:

• macOS with Chrome/Safari developer tools
• Simulated various mobile viewport sizes
• Tested responsive behavior with real operation content

Screenshots

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed